This is probably an api change.

This is probably an api change.

I could be wrong...

Why don't we keep the old name as well, then it's not a breaking change.
We can even:

• Mark the old field name as deprecated so that people using it get a warning.
• Use the @nodoc annotation in a documentation comment so that it doesn't have to be displayed in the generated documentation.

If we are really bold, we could take a step further and try to use data driven fixes.
We'd simply create a lib/fix_data.yaml file which says how to rename.

version: 1
transforms:
  - title: 'Rename to GreaterThan'
    date: 2024-09-11
    element:
      uris: ['datastore.dart']
      field: 'GreatherThan'
      inClass: 'FilterRelation'
    changes:
      - kind: 'rename'
        newName: 'GreaterThan'

Then someone running dart fix --apply will get:

$ dart fix --apply
Computing fixes in gcloud...   2.1s
Applying fixes...                      0.0s

lib/src/datastore_impl.dart
  deprecated_member_use_from_same_package • 1 fix

test/datastore/e2e/datastore_test_impl.dart
  deprecated_member_use_from_same_package • 1 fix

2 fixes made in 2 files.

And a git diff as follows:

diff --git a/lib/src/datastore_impl.dart b/lib/src/datastore_impl.dart
index d62868c..ac976c7 100644
--- a/lib/src/datastore_impl.dart
+++ b/lib/src/datastore_impl.dart
@@ -205,7 +205,7 @@ class DatastoreImpl implements datastore.Datastore {
     datastore.FilterRelation.LessThan: 'LESS_THAN',
     datastore.FilterRelation.LessThanOrEqual: 'LESS_THAN_OR_EQUAL',
     datastore.FilterRelation.Equal: 'EQUAL',
-    datastore.FilterRelation.GreatherThan: 'GREATER_THAN',
+    datastore.FilterRelation.GreaterThan: 'GREATER_THAN',
     datastore.FilterRelation.GreatherThanOrEqual: 'GREATER_THAN_OR_EQUAL',
   };

diff --git a/test/datastore/e2e/datastore_test_impl.dart b/test/datastore/e2e/datastore_test_impl.dart
index 120ec5e..4e764df 100644
--- a/test/datastore/e2e/datastore_test_impl.dart
+++ b/test/datastore/e2e/datastore_test_impl.dart
@@ -780,7 +780,7 @@ void runTests(Datastore datastore, String? namespace) {
       assert(indexedEntity.length == 1);

       var filters = [
-        Filter(FilterRelation.GreatherThan, queryKey, queryLowerBound),
+        Filter(FilterRelation.GreaterThan, queryKey, queryLowerBound),
         Filter(FilterRelation.LessThan, queryKey, queryUpperbound),
       ];
       var listFilters = [

I think this is worth splitting out into a separate PR, just because doing these renames is somewhat non-trivial.

However, doing them without breaking the API is really cool. And being able to have the changes fixed with dart fix --apply is AWESOME 🚀

This was my first time trying to make a data driven fix, but it was surprisingly easy!

It's a bit sad that the data driven fix didn't show up in the "quick fix" menu offered in vscode by the LSP. Maybe, that'll happen one day.

You could file a ticket against them 😉

Split into #193

Hmm, actually the documentation says that lib/fix_data.yaml is used for quick fixes.

Not sure why it doesn't work, maybe the lint doesn't trigger it, or?

At-least there is an issue for adding testings for it:
dart-lang/sdk#53768

https://github.com/flutter/flutter/blob/9108b6d0cff1eb95377153559c01d48f725760ba/docs/contributing/Data-driven-Fixes.md?plain=1#L93

The version key is required. The value of the version key is an integer used to identify the version of the file's content. The version described by this document is version 1. The version key is typically the first line of the file.

I can't tell if they mean that the version of the file format or the version of the file's content. While the text says the latter, it feels like it means the former, unless by document it means example file.

-- I'm happy to file PRs to places, but won't until I have a better understanding of the magic involved.